At present, online and web-based transactions make up a significant and increasing amount of card (or cardholder) not present (CNP) transactions. Because the card is not present during these transactions, the possibility of fraud is much higher than in transactions in which the card is present. To prevent fraud it is important for a merchant to validate and authenticate a card even though the card is not present.
Recently, card issuers and other financial institutions have implemented the use of standardized Internet transaction protocols in an effort to improve online transaction security and to accelerate the growth of electronic commerce. Under some standardized protocols, card issuers or issuing banks may authenticate transactions thereby reducing a likelihood of fraud and chargebacks attributed to cardholder not-authorized transactions. One example of such a standardized protocol is the Three Domain Secure (3-D Secure) protocol. Merchants that register for the 3D Secure protocol may be assured by card issuers or issuing banks that they will be reimbursed for failed transactions which are authenticated using the 3D Secure protocol. Furthermore, the 3D Secure protocol is consistent with and underlies the authentication programs offered by card issuers such as MasterCard SecureCode, Verified by Visa, American Express SafeKey, and others, which are used to authenticate customers on behalf of merchants during remote transactions such as card not present (CNP) transactions performed through the Internet.
The 3D Secure protocol uses existing Secure Sockets Layer (SSL) encryption functionality and provides enhanced security through an issuer authentication of a cardholder during an online shopping session. Authentication software, which may be referred to as a Merchant Plugin (MPI), may be used by participating merchants to exchange messages, pass information and query participants in order to establish an authentication session between the cardholder and the card issuer during an online purchase.
While transacting with 3D Secure compliant banks and merchants, a cardholder may experience the same Internet shopping procedure as previously, except that the cardholder may receive a separate authentication window from the cardholder's bank to determine if they are indeed the cardholder of record. The transaction flow for an online purchase transaction under the protocol relies heavily on the merchant. For example, the cardholder typically may fill in payment data on a merchant web site through an encrypted Secure Sockets Layer (SSL) connection. In response, the merchant sends a message to a directory server or system which in turn queries the card issuer to find out whether the cardholder is enrolled in the 3D Secure program. The card issuer responds to the directory server with a message indicating whether the cardholder is enrolled and, if so, provides a Web address for the financial institution that issued the card (i.e., the issuer or issuing bank). This message is then processed and a response forwarded to the merchant.
Next, the merchant sends a message to the issuing bank to initiate an authentication session between the cardholder and the issuer in which transaction details such as merchant name and transaction amount may also be presented to the cardholder for confirmation. The issuing bank populates an authentication window of the cardholder detailing information related to the transaction such as a merchant name, a transaction amount, a personal security message, and a response area where authentication details can be entered by the cardholder. If the authentication is valid, the issuer sends a message to the merchant indicating the transaction was successful.
During the 3D Secure authentication process, cardholder information is transmitted between the merchant and multiple devices over a public network such as the Internet. As a result, oftentimes indirect and overlapping communication is performed between the merchant and these devices in order to validate a cardholder. In addition, the cardholder information may include sensitive cardholder data, for example, a primary account number (PAN), an expiration date, a card security code, and/or the like, of the cardholder's account. As a result, the sensitive cardholder information is at risk each time it is being transmitted by the merchant over the Internet. Furthermore, there is also a risk that the authentication process may be dropped or otherwise lost, for example, as a result of a service failure of the merchant, the MPI software being corrupted, an aggregator service, and the like.
Throughout the drawings and the detailed description, unless otherwise described, the same drawing reference numerals will be understood to refer to the same elements, features, and structures. The relative size and depiction of these elements may be exaggerated or adjusted for clarity, illustration, and/or convenience.